Intelligent Web Interface Design for Climate Model Post-Processing Scripts using Feature Modelling

This paper details the process of designing a web interface providing access to running climate model post-processing scripts on both local and external climate model output data such as the CMIP5 dataset. Feature Modelling is used to provide a automated statistical method of identifying relationships between post-processing scripts, as well as raising the possibility of automatically generating a graphical user interface tailored to each script. The advantages and disadvantages of Feature Modelling are discussed alongside the available methods used to generate the feature models. I. PROBLEM STATEMENT In climate simulation, after a model is run, the output data is analysed by climate scientists via manipulation of data, usually through custom scripts that produces output in forms including both numerical data and visual data such as plots, graphs, image comparisons, animations, etc. These scripts are called post-processing scripts (PP Scripts) as they are done after a climate model is already run. They often do not follow any one standard format for input and output interfacing, and the dependencies of the script vary also. A PP script usually utilizes as input both higher-level options such as the start and end dates, model data used, variable name, etc.. It also contains lower-level options such as file locations and model data chunk lengths, which is how the output data from a model is divided up into multiple files in yearly format. The actual PP scripts examined include the scripts written for use at the Geophysical Fluid Dynamics Laboratory (GFDL), where over 780 scripts written by multiple scientists exist for use with internal data. A majority of these scripts are written in C shell [?], with some scripts utilizing FORTRAN, MATLAB, and Ferret scripts as well. The ability to share these scripts with other scientists requires technical knowledge of the scripts input parameters, something that is not common between all scripts. Also, many similar scripts may not work directly with models outside of a research lab as there are often differing naming conventions. For only a few scripts, it is possible for scientists to share the actual files through personal means, describing the process of using the script in-person, including the conversions needed to use a specific model data output; however, for a more general case where hundreds of these analysis scripts have been written it becomes necessary to implement a system that can provide an intuitive and standardized interface to access and run a PP script of choice on general model data output. One such effort to provide access to Post-Process scripts is GFDL’s Data Portal LAS (Live Access Server), which provides access a suite of basic analyses on GFDL’s CM2.x climate model output through the Curator Portal. This system is a powerful proof-of-concept to the possibilities of web interface designs. In the long term a system that automates the selection or conversion of input datasets needed for an analysis script will provide better access to tools for climate scientists to use. In the design of this user interface to climate data and analyses, it also opens up the possibility of providing general data to scientists and the public outside of a specific research lab.